Today's computer modules, especially those utilizing processors, are highly complex, both in their physical layout and in their logical capabilities. This complexity leads to many possibilities for defects and contributes significantly to the difficulty in locating these defects. In the past, when computer modules were simple and less expensive, and basic testing could not locate a defect, the most cost-effective solution may have been to discard the module. However, present computer modules are significantly more complex and very costly both in material costs as well as in manufacturing costs. It is not cost-effective to discard defective modules. Instead, complex test equipment and testing methods must generally be employed to precisely identify and locate defects, such that effective repairs can be made.
The purpose of testing a computer module is to determine, first, if the computer module has any defects and, if so, to locate these defects such that they can be repaired. Hence, an expensive computer module can be salvaged rather than discarded. Error detection may be costly, both in terms of the test equipment required and a technician's time to perform testing. Moreover, subsequent module repair may damage the module under test (MUT) when components are removed, wires added, etch cut, etc. Because of this, computer module testing strives for precise definition of the defects to increase the possibility that the module will be functional upon repair and to decrease the possibility that the module may have additional defects and require further testing and repair.
A common technique for testing complex modules with on-board processors involves the addition of test sequences to the processor's initialization code. Many processor-based computer modules have Read-Only Memory (ROM) components which supply code utilized by the processor during initialization. The inclusion of test sequences with the initialization code stored in the ROM allows the processor to initialize and test itself, and begin testing other components on the module. The code utilized during initialization may also contain a pointer to additional code stored in other memory components on the MUT. The additional code stored in these memory components comprises more extensive test sequences.
Frequently, the processor on the MUT must rely on a substantial amount of untested hardware also on the MUT to retrieve the code utilized during initialization from the ROM. This hardware usually comprises highly integrated components capable of executing complex commands and may generally include a combination of a large number of components with high pin counts and connections, leading to many possibilities for defects. If the module has a defect in the hardware relied upon to retrieve the code, the processor may not be able to access the ROM or the code retrieved may be corrupted. This may render the module untestable. If the ROM containing the code is directly connected to the processor, then this problem may be substantially eliminated because few connections or other components need be relied upon.
The processor typically loads the code utilized during initialization into an internal instruction cache (I-cache) and therefore, the amount of code accepted by the processor is usually limited by the size of the processor's I-cache. More extensive test sequences which may be expressed in more code than can be loaded during initialization may be needed to fully test the module in order to precisely locate any defects. Memory components on the MUT external to the processor may be used to store extensive test sequences, but are generally not directly connected to the processor. Therefore, to retrieve the extensive test sequences a substantial amount of untested hardware may need to be relied upon leading to the difficulties discussed above.
Once the test sequences are retrieved and executed by the processor, status reporting is usually accomplished through some general manifestation of a pass or fail condition on the module itself. For example, a light emitting diode (LED) may be activated by the processor if the module passes all the tests within the test sequence or remain deactivated if the module fails any tests. If a failure is indicated in such a way, there may be no information available as to which of multiple tests within a testing sequence the module failed or what the defect might be.
Another testing method involves the application of digital logic patterns to the MUT from an external source and the reception of resulting digital logic patterns from the MUT which may then be compared to known correct patterns to determine if there is an error. Electrical contact to the points on the module used for pattern application and/or reception is required. These may be in many different locations, such as the module's edge connectors, various nodes (points at which components are connected) located on the module, or the pins of processor chips or other integrated circuit components. The most familiar type of test equipment used in applying and receiving patterns is the "bed of nails" tester, where one "nail" is used to electrically contact a node of the MUT and apply or receive patterns from the node.
Often nodes required to test the MUT may not be accessible for contact by a nail. This may be due to the node being hidden under a double-sided-surface mounted component or due to the node being buried in a multi-layer printed circuit board.
In order to fully test complex module's of the type to which the invention pertains, a large number of test patterns are generally required. The test equipment may not be able to store a sufficient subset of the large number of patterns required to fully test the module, and therefore, the test equipment may not be able to fully test the module. The test equipment must store not only the patterns to be applied, but also the patterns received and the patterns to which the received patterns will be compared. Moreover, the test equipment may not be able to operate at the speed at which the processor is capable of operating, and errors which may only occur at the higher operating speed of the processor may not be detectable at lower operating speeds.
Test equipment which applies patterns to the MUT and receives resulting patterns from the MUT is intrusive in that there is physical contact between the test equipment and the MUT. This contact may itself create defects by causing damage to the MUT in the form of cut or interrupted etch (opens), broken pins, etc. The test equipment may also conceal already existing defects by temporarily alleviating the defect. For example, an open between two pieces of etch or between a component pin and its associated module pad may be bridged when the contact by the test equipment completes the circuit.
Another testing method which has been used for complex modules replaces the ROM which stores the code utilized by the processor during initialization with a plug-type connector attached to the MUT where the ROM pins would normally be attached. The plug-type connector allows attachment to test equipment through a cable. The test equipment can provide the processor with code which includes initialization code as well as test sequences to be executed by the processor. This allows new test sequences to be loaded into the processor by re-initializing the processor instead of removing the ROM and blasting new code into the ROM each time new sequences are needed.
Many of the difficulties associated with testing methods which include initialization code and test sequences in the ROM itself may also be experienced when using this ROM replacement testing method. As previous pointed out, if the processor needs to rely on a significant amount of untested hardware to access the ROM, this ROM replacement testing method may not be particularly useful. Also, as previously mentioned, the amount of code accepted by the processor during initialization may be limited which may prevent the loading of comprehensive tests. Incremental loading of comprehensive tests may also not be possible through this ROM replacement testing method, because for additional test sequences to be loaded, the processor needs to be re-initialized, which would erase any previously loaded code. Additionally, as pointed out above, status reporting may be limited to manifestations on the MUT. A pass/fail indication provides no information about which test the module failed or what type of defect is present.
Replacing the ROM with a plug-type connector may prevent testing the MUT in conjunction with the computer system for which the MUT was designed to be utilized. The plug-type connector may require more space than what is available between modules properly seated in the intended computer system. In order to use this connector while the MUT is connected to its intended computer system, the MUT may have to be connected to an extender card. An extender card extends the electrical and physical connections between the MUT and the computer system such that the MUT may be electrically connected to the computer system, but physically stand out from the other modules making up the computer system. One difficulty is that often today's computer systems depend on the precise timing and loading of signals on the system bus. The increased physical length of the electrical connections between the module and the computer system may add timing delay and capacitive loading to the signals. This change to the signal's characteristics may not permit the MUT to properly operate in the computer system. Therefore, it may not be possible to test the MUT in conjunction with the computer system using test equipment connected to a plug-type connector on the MUT.
Once a defect is reported, a more precise definition of the defect may be needed to make effective repairs to the module. New test sequences may be written and loaded into the processor. However, the amount of test code required to recreate the error and continue testing beyond the point where the error occurs may be too large for the processor to accept during initialization. Thus, the test equipment may be unable to determine the defect more precisely. In the case of intermittent errors, it may be very difficult to recreate the error at all.
The ROM replacement test method is intrusive, due to the physical contact between the module and the plug-type connector replacing the ROM and the necessity of removing the ROM prior to attaching the connector. Many of the difficulties mentioned with regard to the intrusiveness of the bed-of-nails tester may occur with this test method as well.
It is therefore desirable to provide a method and apparatus which allows a complex computer module to be dynamically and comprehensively tested and which avoids the foregoing and other disadvantages of known methods and apparatus. It is to these ends the present invention is directed.